The present invention generally relates to a device interface controller and, in particular, relates to one such device interface controller that provides communication and control information for a plurality of peripherals.
Since the advent of data communications, a major task has been the efficient control of peripherals. Historically, this task has been, and remains, difficult, not only because of the variety of peripherals available, e.g., workstations, printers, or the like, but also because of the variety of operating data rates and different manufacturer specifications thereof. The task is further complicated by the variety of microprocessing devices available, most of which are unable to directly exchange information with a peripheral and therefore require some form of a device interface controller to allow communications between a peripheral and a microprocessor controlling the flow of data.
One conventional resolution of these difficulties has been to include a device interface controller that contained a set of instructions, i.e. a dedicated program, designed to control a specific peripheral. In addition, a data storage medium, such as a random access memory (RAM), was introduced between the microprocessor device and the device interface controller. In operation, the microprocessor device would transfer a bit of information into the storage medium via the local bus thereof. The microprocessor would then transfer this single piece of information to the device interface controller. The peripheral would then be controlled, in accordance with the stored program, to accept the information. The device interface controller, upon completing the bit transfer, would interrogate the storage medium, or simply become idle, to obtain the next information to be transferred. The storage medium would contain instructions that would cause, once the information had been transferred to the device interface controller, the microprocessor device to be interrupted, frequently regardless of the task being performed thereby, to request the next information.
This transfer process is clearly extremely slow and inefficient. Thus, present systems generally include expanded registers into which the microprocessor device provides larger amounts of information, which information is then relayed to the peripheral via the device interface controller. The advantage gained by this technique is an increase in the time interval between interrupts from the storage medium to the microprocessor device.
Nevertheless, most conventional systems frequently require information to be transferred between the microprocessor device and the storage medium along the local bus of the microprocessor. This same local microprocessor bus is also utilized to transfer information between the storage medium and the device interface controller. Consequently, in addition to interrupting the microprocessor for further instructions, the microprocessor is interrupted, i.e., removed from access to the local bus thereof, during the actual transfer of data between the storage medium and the device interface controller. Consequently, the microprocessor frequently has insufficient access to the local bus thereof to enable it to control more than a single peripheral at any given time.
One conventional solution to this inefficient arrangement is to provide an additional set of instructions, separate from the microprocessor, for the device interface controller. This approach thus unloads some of the functions ordinarily performed by the microprocessor and hence, improves the overall operating speed of the microprocessor. To date, however, the program of fixed instructions has been stored within the storage medium thereby reducing the memory capacity available to the entire system and increasing traffic therethrough thus limiting access to the bus of the microprocessor. The inherent trade-off of this technique is an increase time between microprocessor interrupts from the storage medium against the reduction of available memory. However, without such a program, the device interface controller is most commonly limited to accessing blocks of continuous data within the storage medium, beginning at an address provided thereto by the microprocessor. Consequently, once that block of data is transferred, the microprocessor device must refill the block and indicate to the device interface controller what and where the address is for that information.
Another major aspect of conventional device interface controllers is that specific control instructions are required for each particular peripheral that it is handling. Hence, by providing such a program within the storage medium, the specific control instructions for the controlled peripheral can be stored therein and, thus, remove further work from the microprocessor. Unfortunately, the inclusion of such specific control instructions requires additional portions of the storage medium, which would ordinarily be used for storing information to be transferred between the microprocessor and the periperal. Thus, present device interface controllers and the microprocessors interfacing therewith are quite limited in the number of peripherals that can be handled thereby by any one, or more, of four basic detrimental conditions. These detrimental conditions are generally referred to as bus latency, bus occupancy, interrupt latency, and interrupt service time.
The condition of bus latency arises because some devices have critical response requirements. That is, failure to respond to a request therefrom within a critical time period often results in the loss of data. The loss of data occurs because new incoming data overrides the data that was to be transferred, or alternately, results in the transmission of meaningless information because the transmit side of the device attempted to retrieve data that had not yet been provided. These situations are complimentary versions of the same thing and are generally referred to as data overrun and data underrun, respectively. Under heavy input/output loads this condition frequently occurs because the local bus traffic of the microprocessor simply does not permit response to local bus requests within the required critical time periods. The most common solution to the bus latency condition is to provide double buffering and utilize a first in-first out (FIFO) system in front of the transfer mechanism to relieve the instantaneous requirements of any device accessing that buffer. Consequently, the bus need only respond to the average short term load. However, such a solution becomes expensive and requires large assemblies as well as an increase in the overall power requirements thereof.
The condition of bus occupancy occurs when the data transfer traffic increases such that it requires a significant portion of the bus bandwidth and, as a consequence, the capacity of the microprocessor to compute is diminished. Such a condition subsequently impacts the entire throughput of the system. Traditionally, this condition has been resolved by distributing the data transfer load over more microprocessors and/or introducing faster microprocessors. Both solutions are quite expensive.
Interrupt latency occurs upon completion of the transfer of information by a device interface controller to the controlled peripheral, whereupon an interrupt is generated to request further data, information, or instructions. The time required for the microprocessor to respond to such an interrupt request may be critical for any one of several reasons. The most important of these reasons is that the failure to respond to such an interrupt can cause the microprocessor to fail to recognize any subsequent interrupt from the same source that occurs before the pending interrupt is acknowledged. Although it is possible for modern devices to respond rapidly to interrupts, a heavy interrupt load on any microprocessor causes delays in responding to subsequent interrupts, i.e., simply overloading the microprocessor results in a backup of interrupts awaiting service while others are being serviced.
The condition of interrupt latency is compounded by the condition of interrupt service times. Even with present interrupt times of, minimally, about one millisecond, in terms of high speed devices, this is a snails pace response. The interrupt service time, i.e., the one millisecond minimum, stems from the simple fact that once an interrupt request has been responded to by the microprocessor, the request, per se, must still be serviced. A typical condition is that a device designed for receiving data, must first be initialized, i.e., put in a ready position, before the first piece of data is transferred thereto. Failure to do this can cause both data overruns and data underruns in the same way as bus latency. Further, initialization requires the transfer of commands and controls to instruct the device where to store the incoming data and ascertaining that it is now eligible to receive data. In addition, error checking, to ensure that previous transmissions have been correctly sent, must also be performed prior to initialization to ensure that initialization does not result in a data overrun. Finally, the microprocessor, in order to execute its program and process data, must have access to the local bus thereof to effect that processing of data, that is the microprocessor must access the bus at least as long as it takes to complete the required processing. This frequently results in difficulties because present device interface controllers require considerable servicing by the microprocessor in order to effectively serve all the interrupts and avoid some of the problems stated above. Consequently, the real task, i.e. computational tasks, of the microprocessor is slowed and becomes effectively bound by the device interface controller.
Thus, the development of faster peripherals and/or faster microprocessors are of limited value without a more comprehensive device interface controller.